[Previous] [Next] [Index]
[Thread]
Re: N$ SSL vs M$ PCT
Bennet Yee writes:
| So, you're right, but the point that you're making is well known.
| All protocols, including PCT, cannot stand if their cryptographic
| keys are carelessly reused in other protocols. However, I don't
| think that you should be pointing your finger at all these protocols
| and declaring that there is a fundamental failure; perhaps the
| problem is really more of a lack of communication between
| cryptographic protocol designers and non-cryptographers such as
| yourself. Crypto people assume that the implementers won't do the
| wrong thing (e.g., use good, cryptographically secure pseudo-random
| number generators that are seeded properly with a seed of sufficient
| length whenever appropriate, not dump core when given unexpected
| inputs, etc) when their protocols are cast into code; sometimes
| that's an invalid assumption.
The failure of a protocol to specify important facts known to
its designers is a specifications failure. The lack of communication
you refer to needs to be addressed in the documents that implementors
are most likely to read, ie, the specifications. As Ross Anderson
points out in his 'Why Cryptosystems Fail' paper, the assumption by
cryptographers that the programmers will know how to write security
code does not hold up in the real world.
Until and unless there is a body of knowledge out there in the
general programing community, it behooves the designers of secure
protocols to specify (possibly by reference) as much as possible.
Adam
--
"It is seldom that liberty of any kind is lost all at once."
-Hume
Follow-Ups:
References: